In order to display the best quality picture via a network of given bandwidth at a given remote endpoint there is considerable latitude in how the picture is encoded. For example, at the sending endpoint a codec must be negotiated, and then the encoder bit rate, the frame rate and the resolution must beset. As the bandwidth of the connection varies, as it does for example using the Internet, so the optimum encoding varies.
The simplest and least satisfactory encoding method is to choose a codec and setting requiring a minimum bandwidth, which makes it difficult to transfer High Definition (HD) videos. In one-way, non real time applications, e.g. TV buffering at the receive endpoint is commonly used to smooth out temporary fluctuations in bandwidth. However due to round trip delay requirements for real time communications it is desirable to minimize receive endpoint buffering.
It is known that encoding may be optimized by continuously measuring round-trip delay, that is to say the time taken for a test packet of data to be transmitted from the sending endpoint (i.e. the endpoint from which a video stream is to be sent) to the receiving endpoint plus the time taken for a test packet of data to be returned to the sending endpoint. RTCP (RFC 3550) is a known industry standard method for collecting statistics from a network connection. From an RTCP Receiver Report it is possible for an endpoint to calculate Round Trip Delay, Jitter, and Packet Loss. Magor U.S. patent application Ser. No. 12/289,946 teaches a method of optimizing video encoding using RTCP reports.
A shortcoming of known methods of optimizing video encoding is that they are affected by limitations of the reverse connection. That is to say optimization is based in part on round trip delay, the sum of the delay in the forward connection plus the reverse connection. Delay of signals traveling in the reverse direction, toward the source of video, has no bearing (more accurately no quantifiable bearing) on the quality of displayed video and may be significantly greater (or less) than the delay in the forward connection. In addition, there is no guarantee that RTCP packets travel through the same forward path from sender to receiver.